How would we convey that change?

I think there's two ways to look at it for this feature:

1. Since this feature is pre-interoperable, it's possible that it will be animatable across browsers by the time everyone has implemented the rest of it. If we think that's likely, then we can include the animation subfeature from BCD now (on the assumption that's what the css.properties.content-visibility.keyframe_animatable feature refers to; see Point content-visibility animation spec to css-contain-3 mdn/browser-compat-data#21120).

2. If we don't think animation will land with the rest of it, then we could create a follow-up feature for animation (e.g., content-visibility-animation or similar).

I think I'm clearer now on the generic mechanism to handle semantic updates. That's good.

I don't feel strongly on whether we should do 1. or 2., but in the absence of more implementation insights, I would follow the CSS working group's own assumptions: level 2 should become stable before level 3. As such, if we want to talk about the feature sooner rather than later, we should probably not include more future-looking level 3 bits.

Once in a while, the assumptions will turn out to be wrong, but that's why they're called "assumptions" and not "assertions"...

I think that right now we don't need to assume anything about whether animation will be supported soon enough to be lumped into this feature. Down the line we'll most likely burn down BCD entries trying to match each to a feature, and then it will be clear if adding it into the content-visibility feature would change computed support or not.